In cellular networks, network signalling messages are regularly used between a visitor registration entity, such as a Visitor Location Register (VLR) and a home registration entity, such as a Home Location Register (HLR). In particular, Supplementary Service (SS) messages can be used to interrogate and/or modify a subscriber's settings on the home registration entity. For example, the mobile application part (MAP) of the Signalling System 7 (SS7) suite is particularly used for this purpose in GSM and UMTS cellular networks. Typically, such operations are generated by the visitor registration entity in response to a subscriber's User Equipment (UE).
It is recognised that such network signalling messages have a low level of security. As a result, it is possible for a third party (which could be an attacker) to imitate such network signalling messages. This may allow them to perform full supplementary service control associated with a victim's subscription. For example, this could include: checking call forwarding settings; deactivating services (such as calling line identification presentation); and activating an unconditional call forward, effectively intercepting all calls to the subscriber.
In current systems, such network signalling messages require an individual subscriber identity, typically an International Mobile Subscriber Identity (IMSI), to be communicated in order to make use of the interrogation and modification functionality. However, this information can be obtained by the imitator simply by making a request of the HLR. Such a request generally results in a response message, comprising the IMSI and the address for the VLR.
In view of this, one main solution to this issue is to deal with the response provided by the HLR. One solution may be to hide the subscriber's true IMSI, for example by use of an SMS home network routeing approach. Examples of such solutions have been marketed by a range of companies. However, this may not provide complete protection, since there may be other methods for determining the IMSI, both directly using the GSM MAP protocol, or indirectly, for example via the management systems of the network operator.
It is therefore desirable to provide some authentication of the network signalling message. A number of solutions have been proposed to achieve this. One option is to use a Transaction Capabilities Application Part (TCAP) handshake protocol, for example as described in 3GPP TS 33.204 Annex D. This is intended to ensure the authenticity of incoming dialogues, by transmitting a first message in the dialogue as empty and providing the payload only in subsequent TC-CONTINUE messages. These may include transaction IDs allocated by the receiving node, which may guarantee the originating address is not imitated. However, commercial agreements may need to be made with roaming partners in order to implement such a solution. Moreover, the protection may only be provided when it is implemented with all roaming partners.
Another approach uses TCAPsec as described in 3GPP TS 33.204. This is similar to TCAP handshake and suffers from the same problems, in which benefits may only be achieved when all roaming partners implement the functionality.
U.S. Patent Publication No. 2010/0105355 describes an alternative solution. A proxy is provided between a VLR and HLR. The proxy receives an Unstructured Supplementary Service Data (USSD) message, which provides an IMSI for the subscriber. The proxy routes the message to another network entity, which queries the HLR for the serving VLR address of the UE identified by the IMSI. The network entity then compares the serving VLR address with the originating VLR address, which is also identified in the USSD message. When these addresses are different, the USSD message is identified as a spoof (that is, imitation). This is a complex solution, including an additional node in the message path and places further burden on the HLR directly.
An improved solution is therefore desirable. Preferably, such a solution need not necessitate all roaming partners from using the functionality, nor should it place a significant burden on the HLR.